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Abstract 


There are a number of contexts in which telephone numbers are 
employed by Session Initiation Protocol (SIP) applications, many of 
which can be addressed by ENUM. Although SIP was one of the primary 
applications for which ENUM was created, there is nevertheless a need 
to define procedures for integrating ENUM with SIP implementations. 
This document illustrates how the two protocols might work in 
concert, and clarifies the authoring and processing of ENUM records 
for SIP applications. It also provides guidelines for instances in 
which ENUM, for whatever reason, cannot be used to resolve a 
telephone number. 
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1. Introduction 


ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS 
(Domain Name Service, RFC 1034 [4]) in order to translate certain 
telephone numbers, like '+12025332600’, into URIs (Uniform Resource 
Identifiers, RFC 2396 [9]), like ‘’sip:user@sipcarrier.com’. ENUM 
exists primarily to facilitate the interconnection of systems that 
rely on telephone numbers with those that use URIs to route 
transactions. E.164 [10] is the ITU-T standard international 
numbering plan, under which all globally-reachable telephone numbers 
are organized. 


SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based 
application protocol that allows two endpoints in the Internet to 
discover one another in order to exchange context information about a 
session they would like to share. Common applications for SIP 
include Internet telephony, instant messaging, video, Internet 
gaming, and other forms of real-time communications. SIP is a 
multi-service protocol capable of initiating sessions involving 
different forms of real-time communications simultaneously. 


The most widespread application for SIP today is Voice-over-IP 
(VoIP). As such, there are a number of cases in which SIP 
applications are forced to contend with telephone numbers. 
Unfortunately, telephone numbers cannot be routing in accordance with 
the traditional DNS resolution procedures standardized for SIP (see 
[14]), which rely on SIP URIs. ENUM provides a method for 
translating E.164 numbers into URIs, including potentially SIP URIs. 
This document therefore provides an account of how SIP can handle 
telephone numbers by making use of ENUM. Guidelines are proposed for 
the authoring of the DNS records used by ENUM, and for client-side 
processing once these DNS records have been received. 


The guidelines in this document are oriented towards authoring and 


processing ENUM records specifically for SIP applications. These 
guidelines assume that the reader is familiar with Naming Authority 
Pointer (NAPTR) records (RFC 3403 [6]) and ENUM (RFC 3761 [1]). Only 


those aspects of NAPTR record authoring and processing that have 
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special bearing on SIP, or that require general clarification, are 
covered in this document; these procedures do not update or override 
the NAPTR or ENUM core documents. 


Note that the ENUM specification has undergone a revision shortly 
before the publication of this document, driven by the update of the 
NAPTR system described in RFC 2915 [12] to the Dynamic Delegation 
Discovery System (DDDS) family of specifications (including RFC 
3403). This document therefore provides some guidance for handling 
records designed for the original RFC 2916 [16]. 


The remainder of this document is organized as follows: Section 3 
suggests general behavior for SIP user agents that encounter 
telephone numbers; Section 4 provides an overview of the intersection 
of SIP and ENUM; proposed normative guidelines for ENUM record 
authoring and processing in the context of SIP are described in 
Section 5, and Section 6 respectively; some considerations relevant 
to the revision of RFC 2916 are given in Section 7. 


2. Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", “SHOULD NOT", "RECOMMENDED", "NOT 
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 
described in RFC 2119 [3] and indicate requirement levels for 
compliant SIP implementations. 


3. Handling Telephone Numbers in SIP 


There are a number of reasons why a user might want to initiate a SIP 
request that targets an E.164 number. One common reason is that the 
user is calling from the PSTN through a PSTN-SIP gateway; such 
gateways usually map routing information from the PSTN directly on to 
SIP signaling. Or a native SIP user might intentionally initiate a 
session addressed to an E.164 number - perhaps because the target 
user is canonically known by that number, or the originator’s SIP 
user agent only supports a traditional numeric telephone keypad. A 
request initially targeting a conventional SIP URI might also be 
redirected to an E.164 number. In most cases, these are requests for 
a telephony session (voice communication), though numerous other 
services are also reached through telephone numbers (including 
instant messaging services). 


Unlike a URI, a telephone number does not contain a host name, or any 
hints as to where one might deliver a request targeting a telephone 
number on the Internet. While SIP user agents or proxy servers could 
be statically provisioned with a mapping of destinations 
corresponding to particular telephone numbers or telephone number 
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ranges, considering the size and complexity of a complete mapping, it 
would be preferable for SIP user agents to be able to query as needed 
for a destination appropriate for a particular telephone number. 


In such cases a user agent might use ENUM to discover a URI 
associated with the E.164 number - including a SIP URI. URIs 
discovered through ENUM can then be used normally to route SIP 
requests to their destination. Note that support for the NAPTR DNS 
resource record format is specified for ordinary SIP URI processing 
in [14], and thus support for ENUM is not a significant departure 
from baseline SIP DNS routing. 


Most of the remainder of this document provides procedures for the 
use of ENUM, but a few guidelines are given in the remainder of this 
section for cases in which ENUM is not used, for whatever reason. 


If a user agent is unable to translate an E.164 number with ENUM, it 
can create a type of SIP Request-URI that contains a telephone 


number. Since one of the most common applications of SIP is 
telephony, a great deal of attention has already been devoted to the 
representation of telephone numbers in SIP. In particular, the tel 


URL RFC 2806 [8] has been identified as a way of carrying telephone 
routing information within SIP. A tel URL usually consists of the 
number in E.164 format preceded by a plus sign, e.g.,: 
tel:+12025332600. This format is so useful that it has been 
incorporated into the baseline SIP specification; the user portion of 
a SIP URI can contain a tel URL (without the scheme string, like 
sip:+12025332600@carrier.com;user=phone). A SIP proxy server might 
therefore receive a request from a user agent with a tel URL in the 
Request-URI; one way in which the proxy server could handle this sort 
of request is by launching an ENUM query itself, and proxying the SIP 
request in accordance with the returned ENUM records. 


In the absence of support for ENUM, or if ENUM requests return no 
records corresponding to a telephone number, local policy can be used 
to determine how to forward SIP requests with an E.164 number in the 
Request-URI. Frequently, such calls are routed to gateways that 
interconnect SIP networks with the PSTN. These proxy server policies 
might be provisioned dynamically with routing information for 
telephone numbers by TRIP [15]. As a matter of precedence, SIP user 
agents should attempt to translate telephone numbers to URIs with 
ENUM, if implemented, before creating a tel URL, and deferring the 
routing of this request to a SIP proxy server. 
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4. Design Principles 


Although the applicability of ENUM to SIP has always been clear, the 
exact way in which the two should cooperate has been a subject of 
some controversy. How many SIP URIs should appear in ENUM, what kind 
of URIs they are, whether or not the "service" field of NAPTR records 
should contain capability information - numerous questions have 
arisen around the authoring, and interpretation of ENUM records for 
SIP consumers. The following, then, is a statement of the particular 
philosophy that has motivated the recommendations in this document: 


Address-of-record SIP URIs appear in ENUM, not contact address 
URIs. Roughly speaking, an address-of-record is the canonical 
identity of a SIP user - it usually appears in the From field of 
SIP requests sent by that user; a contact address is the URI of a 
device. The process of registration in SIP (using the REGISTER 
method), for example, temporarily binds the contact address of a 
device to the address-of-record of a user. A DNS record has a 
long time-to-live when compared with the timeframe of SIP 
registrations. The availability of an address-of-record also 
transcends the availability of any single device. ENUM is more 
suitable for representing an long-term identity than the URI of 
any device with which a user is temporarily associated. If ENUM 
were purposed to map to specific devices, it would be better to 
translate telephone numbers to IPv4 addresses than to URIs (which 
express something richer). 


SIP URIs in ENUM do not convey capability information. SIP has 
its own methods for negotiating capability information between 
user agents (see SDP [13], the use of Require/Supported to 
negotiate extensions in RFC 3261, and callee capabilities [11]); 
providing more limited capability information within ENUM is at 
best redundant and at worst potentially misleading to SIP’s 
negotiation system. Also, addresses-of-record do not have 
capabilities (only devices registered under an address-of-record 
have actual capabilities), and putting contact addresses in ENUM 
is not recommended. 


Only one SIP URI, ideally, appears in an ENUM record set for a 
telephone number. While it may initially seem attractive to 
provide multiple SIP URIs that reach the same user within ENUM, if 
there are multiple addresses at which a user can be contacted, 
considerably greater flexibility is afforded if multiple URIs are 
managed by a SIP location service that is identified by a single 
record in ENUM. Behavior for parallel and sequential forking in 
SIP, for example, is better managed in SIP than in a set of ENUM 
records. 
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User agents, rather than proxy servers, should process ENUM 
records. The assumptions underlying the processing of NAPTR 
records dictate that the ENUM client knows the set of enumservices 
supported by the entity that is attempting to communicate. A SIP 
proxy server is unlikely to know the enumservices supported by the 
originator of a SIP request. 


Authoring NAPTR Records for SIP 


This document makes no assumptions about who authors NAPTR records 
(service providers or end users), nor about any mechanisms by which a 
record, once it is authored, may be uploaded to the appropriate DNS 
servers. Authorship in the context of this document concerns only 
the processes by which the NAPTR records themselves are constructed. 


There are a few general guidelines which are applicable to the 
authoring of DNS records that should be considered by the authors of 
ENUM NAPTR record sets. The most important is that authors SHOULD 
keep record sets relatively small - DNS is not optimized for the 
transference of large files. Having five or six NAPTR records is 
quite reasonable, but policies that encourage records sets of 
hundreds of NAPTR records are not appropriate. Also, DNS records are 
relatively permanent; authors SHOULD NOT use ENUM NAPTR records to 
express relationships between E.164 numbers and URIs that potentially 
exist for only a short time. DNS is most scalable when it can assume 
records will be valid for a reasonable length of time (at least 
several hours). 


1. The Service Field 


The Service field of a NAPTR record (per RFC 3403) contains a string 
token that designates the protocol or service associated with a 
particular record (and which imparts some inkling of the sort of URI 
that will result from the use of the record). ENUM [1] requires the 
IANA registration of service fields known as "enumservices". 


An enumservice for SIP has been developed in the ENUM working group 
(see [7]) which uses the format ‘’E2U+sip’ to designate that a SIP 
address-—of-record appears in the URI field of a NAPTR record. It is 
strongly RECOMMENDED that authors of NAPTR records use the ’E2U+sip’ 
service field whenever the regexp contains a SIP address-of-record 
URI. 


-2. Creating the Regular Expression: Matching 


The authorship of the regular expression (henceforth regexp) ina 
NAPTR record intended for use by ENUM is vastly simplified by the 
absence of an antecedent in the substitution (i.e., the section 


Peterson, et al. Informational [Page 6] 


RFC 3824 SIPPING E.164 June 2004 


between the first two delimiters). It is RECOMMENDED that 
implementations use an exclamation point as a delimiter, since this 
is the only delimiter used throughout the ENUM core specification. 


When a NAPTR record is processed, the expression in the antecedent is 
matched against the starting string (for ENUM, the telephone number) 
to assist in locating the proper record in a set; however, in ENUM 
applications, since the desired record set is located through a 
reverse resolution in the e164.arpa domain that is based on the 
starting string, further analysis of the starting string on the 
client side will usually be unnecessary. In such cases, the 
antecedent of the regular expression is commonly ‘greedy’ - it uses 
the regexp ’%*%.*S’, which matches any starting string. Some authors 
of ENUM record sets may want to use the full power of regexps, and 
create non-greedy antecedents; the DDDS standard requires that ENUM 
resolvers support these regexps when they are present. For providing 
a trivial mapping from a telephone number to a SIP URI, the use of a 
greedy regexp usually suffices. 


Example: "!%*.*S!sip:user@example.com!" 


Note that when the antecedent of the regexp is greedy, this does not 
mean that the replacement field in NAPTR records provides a viable 
alternative to authoring with a regexp. Authors of NAPTR records for 
ENUM MUST NOT use the replacement field in records with an ’E2U+sip’ 
service field. 


5.3. Creating the Regular Expression: The URI 


The consequent side of a regexp contains a URI; NAPTR records that 
are intended to be used for session initiation (including SIP 
telephony) SHOULD use a SIP URI. While this may not sound especially 
controversial at first hearing, there are other sorts of URIs that 
might be considered appropriate for SIP applications: ’tel’ URIs, 
‘im’ or '’pres’ URIs, or others that describe specific services that 
might be invoked through SIP are all potentially candidates. While 
the use of these URIs might seem reasonable under some circumstances, 
including these in NAPTR records rather than SIP URIs could weaken 
the proper composition of services and negotiation of capabilities in 
SIP. 


It is RECOMMENDED that authors of ENUM records should always use the 
SIP or SIPS URI scheme when the service field is ’E2U+sip’, and the 
URIs in question MUST be addresses-of-record, not contact addresses. 


Users of SIP can register one or more contact addresses with a SIP 
registrar that will be consulted by the proxy infrastructure of an 
administrative domain to contact the end user when requests are 
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received for their address-of-record. Much of the benefit of using a 
URI comes from the fact that it represents a logical service 
associated with a user rather than a device - indeed, if ENUM needs 
to target specific devices rather than URIs, then a hypothetical 
‘'E2TPv4+sip’ enumservice would be more appropriate. 


-4. Setting Order and Preference amongst Records 


For maximal compatibility authors of ENUM records for SIP SHOULD 
always use the same order value for all NAPTR records in an ENUM 
record set. If relative preference among NAPTR records is desirable, 
it should be expressed solely with the preference field. 


5. Example of a Well-Formed ENUM NAPTR Record Set for SIP 


SORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. 
IN NAPTR 100 10 "u" "E2U+sip" "I*4.*S!sip:user@example.com!" 
IN NAPTR 100 20 "u" "E2U+mailto" "!%*.*S!mailto:info@example.com!" 


Processing ENUM Records 


These guidelines do not by any means exhaustively describe the NAPTR 
algorithm or the processing of NAPTR records; implementers should 
familiarize themselves with the DDDS algorithm and ENUM before 
reviewing this section. 


Although in some cases, ENUM record sets will consist only a single 
E2U+sip’ record, this section assumes that integrators of ENUM and 
SIP must be prepared for more complicated scenarios - however, just 
because we recommend that clients should be generous in what they 
receive, and try to make sense of potentially confusing NAPTR 
records, that does not mean that we recommend any of the potentially 
troublesome authoring practices that make this generosity necessary. 


` 


1. Contending with Multiple SIP records 


If an ENUM query returns multiple NAPTR records that have a service 
field of ’E2U+sip’, or other service field that may be used by SIP 
(such as ’E2U+pres’, see [17]) the ENUM client must first determine 
whether or not it should attempt to make use of multiple records or 
select a single one. The pitfalls of intentionally authoring ENUM 
record sets with multiple NAPTR records for SIP are detailed above in 
Section 4. 


If the ENUM client is a user agent, then at some point a single NAPTR 
record must be selected to serve as the Request-URI of the desired 
SIP request. If the given NAPTR records have different preferences, 
the most preferred record SHOULD be used. If two or more records 
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share most preferred status, the ENUM client SHOULD randomly 
determine which record will be used, though it MAY defer to a local 
policy that employs some other means to select a record. 


If the ENUM client is a SIP intermediary that can act a redirect 
server, then it SHOULD return a 3xx response with more than one 
Contact header field corresponding to the multiple selected NAPTR 
records in an ENUM record set. If the NAPTR records have different 
preferences, then ’q’ values may be used in the Contact header fields 
to correspond to these preferences. Alternatively, the redirect 
server MAY select a single record in accordance with the NAPTR 
preference fields (or randomly when no preference is specified) and 
send this resulting URI in a Contact header field in a 3xx response. 


Otherwise, if the ENUM client is a SIP intermediary that can act as a 
proxy server, then it MAY fork the request when it receives multiple 
appropriate NAPTR records in an ENUM record set. Depending on the 
relative precedence values of the NAPTR records the proxy may wish to 
fork sequentially or in parallel. However, the proxy MUST build a 
route set from these NAPTR records that consists exclusively of SIP 
or SIPS URIs, not other URI schemes. Alternatively, the proxy server 
MAY select a single record in accordance with the NAPTR preference 
fields (or randomly when no preference is specified, or in accordance 
with local policy) and proxy the request with a Request-URI 
corresponding to the URI field of this NAPTR record - though again, 
it MUST select a record that contains a SIP or SIPS URI. Note that 
there are significant limitations that arise if a proxy server 
processes ENUM record sets instead of a user agent, and that 
therefore it is RECOMMENDED that SIP network elements act as redirect 
servers rather than proxy servers after performing an ENUM query. 


6.2. Processing the Selected NAPTR Record 


Obviously, when an appropriate NAPTR record has been selected, the 
URI should be extracted from the regexp field. The URI is between 
the second and third exclamation points in the string. Once a URI 
has been extracted from the NAPTR record, it SHOULD be used as the 
Request-URI of the SIP request for which the ENUM query was launched. 


SIP clients should perform some sanity checks on the URI, primarily 
to ensure that they support the scheme of the URI, but also to verify 
that the URI is well-formed. Clients MUST at least verify that the 
Request-URI does not target themselves. 


Once an address-of-record has been extracted from the selected NAPTR 
record, clients follow the standard SIP mechanisms (see [14]) for 
determining how to forward the request. This may involve launching 
subsequent NAPTR or SRV queries in order to determine how best to 
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route to the domain identified by an address-of-record; clients 
however MUST NOT make the same ENUM query recursively (if the URI 
returned by ENUM is or contains a tel URL, see [8]). 


Note that SIP requests based on the use of NAPTR records may fail for 
any number of reasons. If there are multiple NAPTR records relevant 
to SIP present in an ENUM record set, then after a failure has 
occurred on an initial attempt with one NAPTR record, SIP user agents 
MAY try their request again with a different NAPTR record from the 
ENUM record set. 


7. Compatibility with RFC 2916 


The ENUM specification is currently undergoing a revision in the ENUM 
WG. The new specification, RFC 3761 [1], is based on the Dynamic 
Delegation Discovery System [5] revision to the NAPTR resource record 
specified in RFC 2915 [12]. For the most part, DDDS is an 
organizational revision that makes the algorithmic aspects of record 
processing separable from any underlying database format (such as the 
NAPTR DNS resource record). 


The most important revision in RFC 3761 is the concept of 
enumservices. The original ENUM specification, RFC 2916, specified a 
number of "service" values that could be used for ENUM, including the 
"SiptE2U" service field. RFC 3761 introduces an IANA registration 
system with new guidelines for the registration of enumservices, 
which are no longer necessarily divided into discreet "service" and 
"protocol" fields, and which admit of more complex structures. In 
order to differentiate enumservices in RFC 3761 from those in RFC 
2916, the string "E2U" is the leading element in an enumservice 
field, whereas by RFC 2916 it was the trailing element. 


An enumservice for SIP addresses-of-record is described in [7]. This 
enumservice uses the enumservice field "E2U+sip". RFC 3761-compliant 
authors of ENUM records for SIP MUST therefore use the "E2U+sip" 
enumservice field instead of the "Sip+E2U" field. For backwards 
compatibility with existing legacy records, however, the ’siptE2U’ 
field SHOULD be supported by an ENUM client that support SIP. 


Also note that the terminology of DDDS differs in a number of 
respects from the initial NAPTR terminology in RFC 2916. DDDS 
introduces the concept of an Application, an Application Specific 
String, a First Well Known Rule, and so on. The terminology used in 
this document is a little looser (it refers to a ’starting string’, 
for example, where /Application Specific String’ would be used for 
DDDS). The new terminology is reflected in RFC 3761. 


Peterson, et al. Informational [Page 10] 


RFC 3824 SIPPING E.164 June 2004 


8. 


9. 


9. 


Security Considerations 


DNS does not make policy decisions about the records that it shares 
with an inquirer. All DNS records must be assumed to be available to 
all inquirers at all times. The information provided within an ENUM 
record set must therefore be considered to be open to the public - 
which is a cause for some privacy considerations. 


Ordinarily, when you give someone your telephone number, you don’t 
expect that they will be able to trivially determine your full name 
and place of employment. If, however, you create a NAPTR record for 
use with ENUM that maps your telephone number to a SIP URI like 
‘julia.roberts@example.com’, expect to get a lot of calls from 
excited fans. 


Unlike a traditional telephone number, the target of a SIP URI may 
require that callers provide cryptographic credentials for 
authentication and authorization before a user is alerted. In this 
respect, ENUM in concert with SIP can actually provide far greater 
protection from unwanted callers than the existing PSTN, despite the 
public availability of ENUM records. 


Users of ENUM who are nevertheless uncomfortable with revealing their 
names may, since identities on the Internet are not exactly at a 
premium, publish a less revealing SIP URI, like 
'sip:anonymous00045@example.com’ or even 
'sip:anonymous00045@anonymous-redirector.example.org’, which could in 
turn point to their internal URI. 


An analysis of threats specific to the dependence of ENUM on the DNS, 
and the applicability of DNSSEC [18] to these, is provided in [1]. 
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